Exchange of Information in a Communication Network

ABSTRACT

Methods and apparatus for managing data objects in a communications network are disclosed. An exemplary method includes storing a plurality of data objects intended for rendering at a first communication device (e.g., a subscriber&#39;s communication device) in response to a triggering communication event, and transferring the plurality of data objects to the first communication device. Apparatus for implementing the preceding techniques are also disclosed.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority to co-pending application Ser.No. 11/140,742 (“the '742 application”), entitled “Exchange ofInformation in a Communication Network” and filed on Jun. 1, 2005, whichis a continuation of application Ser. No. 09/686,990, filed on Aug. 23,2000 and issued as U.S. Pat. No. 6,922,721 on Oct. 17, 2000 (“the '721patent”). The present application is related to application Ser. No.09/644,307, filed on Aug. 23, 2000 and issued on Feb. 7, 2006 as U.S.Pat. No. 6,996,072 (“the '072 patent”), which claimed priority toprovisional application 60/176,806 (“the '806 application”), filed onJan. 19, 2000. The entire contents of each of the '742 application, the'721 patent, the '072 patent, and the '806 application are incorporatedherein by reference.

BACKGROUND

The present invention generally relates to the exchange of informationin a communication system. More specifically, the present inventionrelates to a method and physical implementation (e.g., system, dataserver, communication device, etc.) for supplying a data object to auser device in a communication system. The present invention alsorelates to a method and physical implementation for receiving the dataobject. The present invention also relates to a method and physicalimplementation for rendering the data object. In a more particularembodiment, the present invention relates to a method and physicalimplementation for providing a data object to a mobile station in amobile communication system, for receipt of the data object by themobile station, and for rendering the data object at the mobile station.

Mobile communication systems and data packet networks (notably, theInternet) have both enjoyed significant success in recent years. Mobilecommunication systems deliver real-time voice communication betweenusers in either analog or digital formats (or in a hybrid format). Onewell known example of a mobile communication system is the Global Systemfor Mobile Communication (GSM). This standard provides voicecommunication to its subscribers using circuit-switched communicationtechnology. In this approach, the system allocates communicationresources to a call for the entire duration of the call. On the otherhand, the Internet primarily delivers digital information to users usingpacket data technology. In this approach, the system uses communicationresources only during the periods in which data is being transmitted.

Efforts have long been underway to merge aspects of traditional mobilecommunication systems with data networks. The evolution of these effortsmay be divided into a number of stages, or “generations.” Namely, firstgeneration (1 G) technology generally pertains to analog “voice-centric”services. Second generation (2G) technology generally pertains to“voice-centric” digital communication services. Third generation (3G)technology generally pertains to high speed broadband services withoptional multimedia communication of voice, video, graphics, audio andother information. Further, 2.5 generation (2.5G) technology generallypertains to high speed services having aspects of both 2G and 3Gservices. For instance, 2.5G technology may utilize General Packet RadioService (GPRS) systems or Enhanced Data Rates for Global Evolution(EDGE) systems.

For example, one known way of supplementing voice communication serviceswith data delivery in a 2G-technology context is through the ShortMessage Service (SMS). In the GSM standard, SMS messages can betransmitted over a Stand-alone Dedicated Control Channel (SDCCH). Inoperation, the communication system initially sends a message to aMobile Switching Center (MSC). The message is then routed and stored ina Short Message Service Center (SMSC). The communication system thenlocates the addressed mobile station and alerts the mobile station thata message will be sent. The mobile station then tunes to the SDCCHchannel that the system will use to send the message. The system thenforwards the message to the mobile station and waits for acknowledgementof receipt by the mobile station. Additional detail regarding the GSMShort Message Service may be obtained from the publication “DigitalCellular Telecommunication System (Phase 2+), Technical Realization ofthe Short Message Service (SMS), Point-to-Point (PP),” GSM 03.40,version 5.4.0, ETSI, November, 1996 (accessible athttp://www.etsi.org/).

The conventional use of SMS messaging to convey information hasdrawbacks. Namely, SMS messages can be transmitted before, during, orafter a voice communication session between users. However, the SMSmessaging and voice communication session proceed in a largelyindependent fashion. Hence, the combination of these two modes ofinformation delivery does not provide a strong sense of an integratedand interrelated multi-media presentation.

Another more advanced way of supplementing voice communication serviceswith data delivery is through 2.5G or 3G technology networks thataccommodate Internet browsing. These systems typically operate byconverting Internet data objects to a format suitable for display at themobile stations. More specifically, a gateway node is used to convertthe data objects to a form which is compatible with the low transmissionrates and small screen sizes typically used by mobile stations. Theconverted data objects are then sent to the mobile stations where theyare rendered for the users' viewing. One markup language that can beused to facilitate the display of Internet data objects at the mobilestations is the Handheld Device Markup Language (HDML), which is modeledafter the familiar Hypertext Markup Language (HTML).

These more advanced systems may also have drawbacks. Namely, a serviceprovider may specifically “earmark” a service for use by a specificclass of terminals (such as 2.5G-compatible terminals). As such,consumers using “less advanced” technology may be barred from receivingthe benefits of the service. This may have the undesirable effect ofreducing the market potential of the service. In extreme cases, this mayhave the effect of preventing the service from “catching on” withconsumers (e.g., by failing to popularize a service with a large body ofcurrent technology users).

There is therefore a general need to provide a more effective techniquefor combining voice communication services with supplementary dataservices.

SUMMARY

The techniques disclosed herein address the above need, as well as otherneeds. According to one embodiment, a technique comprises: (a) creatinga data object intended for rendering at a first communication device(e.g., a subscriber's communication device), the rendering to take placeupon the occurrence of a triggering communication event, the data objectproviding information pertaining to a user of a second communicationdevice (e.g., a “holder's” communication device); (b) storing the dataobject in a data server; (c) transferring, in a first transferring step,the data object from the data server to the second communication device(e.g., the holder's communication device); (d) transferring, in a secondtransferring step, the data object from the second communication deviceto the first communication device (e.g., the subscriber's communicationdevice); (e) determining whether the triggering event has occurred; and(f) rendering the data object at the first communication device (e.g.,the subscriber's communication device) upon the occurrence of thecommunication event.

In another embodiment, the technique comprises the steps of: (a)creating a data object intended for rendering at a first communicationdevice (e.g., a subscriber's communication device), the rendering totake place upon the occurrence of a triggering communication event, thedata object providing information pertaining to a user of a secondcommunication device (e.g., a “holder's” communication device); (b)storing the data object in a data server; (c) transferring the dataobject from the data server to the first communication device (e.g., thesubscriber's communication device); d) determining whether thetriggering event has occurred; and (e) rendering the data object at thefirst communication device (e.g., the subscriber's communication device)upon the occurrence of the communication event.

The disclosed invention also pertains to a physical implementation ofthe above-identified techniques. More specifically, the disclosedinvention also pertains to a data server and user device for use inimplementing the above identified techniques.

In one embodiment, data object transfer is performed using one or moreof: (a) a data path used by a circuit-switched communication system; (b)a data path used by a packet-switched communication system; and/or (c) adata path used by a data-packet network.

In one embodiment, the data object comprises a variable portion and anon-variable portion. The transfer of data objects comprisestransferring only the variable portion to the first and/or secondcommunication devices.

The techniques described herein provide a number of benefits. Forinstance, the interrelationship of data object presentation andcommunication events enhances a user's communication session by adding amulti-media dimension to the communication session. Further, thetechnique for the delivery of data objects may be implemented using awide variety of different types of communication systems, data networksand user devices, thus allowing current systems to use the techniques aswell as more advanced systems. For instance, the technique can be usedwith at least 2G, 2.5G and 3G communication technology. Thus, forinstance, a user may continue to receive the benefits of the service inseamless fashion as he or she upgrades from one generation of technologyto another. Other benefits will be apparent to those skilled in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can be understood more completely by reading thefollowing Detailed Description of exemplary embodiments, in conjunctionwith the accompanying drawings, in which:

FIG. 1 shows an exemplary system for implementing the techniquesdescribed herein;

FIG. 2 shows an exemplary user device that can be used in the system ofFIG. 1;

FIG. 3 shows an exemplary Subscriber Identification Module (SIM) cardthat can be used in the user device of FIG. 2;

FIG. 4 shows an exemplary data server for use in the system of FIG. 1;

FIG. 5 shows an exemplary presentation of a series of data objects at auser device;

FIG. 6 shows an exemplary composition of a data object;

FIG. 7 shows an exemplary organization of data objects in the dataserver shown in FIG. 4;

FIG. 8 shows an exemplary procedure for forwarding data objects tosubscribers, according to one embodiment;

FIG. 9 shows an exemplary transfer path of data objects pursuant to theprocedure of FIG. 8;

FIG. 10 shows an exemplary procedure for forwarding data objects tosubscribers, according to another embodiment;

FIG. 11 shows an exemplary transfer path of data objects pursuant to theprocedure of FIG. 10;

FIG. 12 shows an exemplary procedure for obtaining and rendering dataobjects at a user device, according to one embodiment;

FIG. 13 shows an exemplary procedure for obtaining and rendering dataobjects at a user device, according to another embodiment;

FIG. 14 shows an exemplary procedure for receiving and processingrequests for data objects at the data server, which complements theprocedure of FIG. 13;

FIG. 15 shows an alternative way of storing data objects in a memory ofa user device;

FIG. 16 shows partition of a data object corresponding to the alternatestorage technique shown in FIG. 15;

FIG. 17 shows an exemplary transfer path of data objects associated withthe alternative storage technique shown in FIG. 15; and

FIG. 18 shows an alternative way of transferring data objects from adata server to a subscriber's user device.

DETAILED DESCRIPTION

1. System Features

The data object delivery technique is described with reference tospecific types of communication systems, standards and protocols tofacilitate explanation. More specifically, the data object deliverysystem is described with particular reference to the Global System forMobile Communication (GSM). However, the technique can be implemented byother types of systems, standards (e.g., IS-136, IS-95, etc.) andprotocols (e.g., TDMA, FDMA, CDMA, etc.).

FIG. 1 illustrates an overview of a system 100 that can implement thetechnique. Referring to the top part of the figure, the system 100includes a mobile communication system 125 based on, for example, theGSM architecture. The system 100 includes a Mobile Switching Center(MSC) 118 connected to a Base Station Controller (SSC) 116 and to aPublic Switched Telephone Network (PSTN) 128. The BSC 116 providescommunicative connection to plural user devices via base station 114.The user devices include exemplary mobile station devices 110 and 112.The PSTN 128 provides communicative connection to plural user devices130 and 132. The user devices 130 and 132 can comprise any type ofcommunication devices, such as “plain old telephones” (POTs), facsimileor data modern devices, etc. The PSTN 128 can also interface (directlyor indirectly) with ISDN terminals and communication devices connectedvia a Digital Subscriber Line (DSL). The PSTN may also optionallyconnect to another mobile communication system 134, which may includeplural user devices, such as mobile station devices 136 and 138.

The MSC 118 performs the switching necessary to interconnect callsbetween user devices using the communication system. The MSC 118 may beconnected to a number of databases, such as authentication center (AuC)120, Home Location Register (HLR) 122, and Visiting Location Register(VLR) 124. These databases are well known to those having skill in theart. Basically, the AuC 120 stores information that is used to validatethe identity of user devices. The HLR 122 stores user profiles whichindicate the services that the users have subscribed to, as well asother information. The VLR 124 stores information that identifies theuser devices that are operating within the domain of the MSC 118. TheAuC 120, HLR 122 and VLR 124 can be physically implemented as part ofthe MSC 118, or may be located remotely from the MSC 118. The messagecenter 126, such as a Short Message Control Center (SMCC), receives,stores and forwards messages transmitted to and from the mobilecommunication system.

It will be apparent to those skilled in the art that the mobilecommunication system 125 may include additional user devices, basestations, BSCs, MSCs, etc. Further, the mobile communication system 125may include additional functionality, nodes, databases, services, etc.

Referring now to the bottom part of the figure, the system 100 alsoincludes a data network 142. The data network 142 may comprise, forinstance, any network configured to transfer information in datapackets. The data network 142 may comprise, for instance, an intranet,the Internet, a LAN (Local Area Network), etc. The data network 142 mayuse any type or combination of network enable code, such as HypertextMarkup Language (HTML), Dynamic HTML, Extensible Markup Language (XML),Extensible Stylesheet Language (XSL), etc. The data network may furtherbe governed by any type or combination of protocols, such as theTransport Control Protocol (TCP), User Datagram Protocol (UDP),HyperText Transport Protocol (HTTP), Wireless Application Protocol(WAP), or other type of protocol.

A number of entities may interact with the data network 142. Forinstance, computer devices 146 and 148 are communicatively coupled withthe data network 142 via Internet service provider 144 in a well knownmanner. Further, plural data servers are communicatively coupled withthe data network 142, such as data server 150.

The data network 142 interfaces with the mobile communication system 125via gateway 140. The gateway 140 broadly represents any platform forconnecting the data network 142 with the mobile communication system125. In one embodiment, the mobile communication system 125 allows forthe exchange of data messages through the Short Messaging Service (SMS).In that case, the gateway 140 provides appropriate translation from thedata network format (such the TCP/IP, HTTP, etc. protocol formats) to anSMS-compatible format (and vice versa for communication in the oppositedirection).

The above-described SMS data path is “featured” in the followingdiscussion to simplify and facilitate the explanation by providing oneconcrete implementation example. However, it should be recognized thatthe system 100 can use a variety of other techniques (besides the SMSdata path) to transfer data between the data network 142 and the mobilecommunication system 125. For instance, the mobile communication systemmay allow for the exchange of data messages through a General PacketRadio Service (GPRS) link, or a variety of other types of links,systems, protocols, etc.

In an alternative embodiment, gateway functionality may be incorporatedin other nodes of the system, such as at the server node.

Exemplary communication paths are illustrated in FIG. 1 with dashedlines. For instance, a party using user device 110 (referred tohereinafter as the “A-party”) may achieve a real-time circuit-switchedvoice connection with a party using user device 138 (referred tohereinafter as the “B-party”) via communication path 160. Further, thedata server 150 may achieve a data connection with the A-party via datapath 154. The data server 150 may achieve a similar data connection withthe B-party via another data path (not shown). Further, a user usingcomputer device 146 may achieve a data connection with data server 150via data path 152.

FIG. 2 shows one of the user devices, i.e., user device 110, whichinterfaces with mobile communication system 125. This user device 110can comprise a mobile station user device (e.g., a mobile telephone), aProgrammable Digital Assistant (PDA) with mobile station capabilities,or some other type of device. The user device 110 includes control logic214 connected to at least one memory unit 212. The memory unit 212 maybe non-volatile (e.g., EEPROM or SIM card) in order to retain storedinformation, should power be temporarily unavailable. The control logic214 also connects to one or more input devices 210, such as a keyboard,touch screen, etc. The control logic 214 also connects to one or morerendering devices 222, such as a display, printer, etc. The controllogic 214 also connects to a radio unit 220 that includes transmitterand receiver hardware (not shown) for transmitting and receiving signalsover the air. The radio unit 220 connects to an antenna 232. The radiounit 220 also directly or indirectly connects to an audio output device216 (such as a speaker and/or earphone) and a microphone 218 to enablevoice communication.

The user device may further comprise additional functionality 230, e.g.,as implemented by a plurality of programs. These programs may include abrowser (not shown) that renders at least one type of data object to auser for viewing. The programs may also include an encryption/decryptionengine (not shown) that encrypts data object requests and decryptsreceived data objects. The user device may optionally include cachememory (not shown) for storing and retrieving frequently used displayobjects, etc.

Other types of user devices can interface with system 100. For instance,another type of user device may comprise a fixed (non-mobile) telephonewith graphic capabilities. Another type of user device may comprise amobile station connected to a Personal Digital Assistance device (PDA)device (or similar device) via a communication link. The PDA includesfunctionality for displaying and manipulating the data objects.

The user device shown in FIG. 2 may embody any generation of technology,including 2G, 2.5G, 3G, etc., technology.

The user device 110 shown in FIG. 2 may interface with the SubscriberIdentification Module (SIM) card 300 shown in FIG. 3. The SIM card 300stores subscription information that identifies the subscriber, such asthe subscriber's telephone number, a unique identification number, andhome system identification information. The unique identification numberfor a GSM subscriber may include an Integrated Mobile Station Identifier(IMSI) number.

As shown in FIG. 3, an exemplary SIM card 300 includes a microprocessor302 coupled to memory 306 and input/output pins 304. The memory 306, inturn, includes operating software storage 308 (e.g., implemented as ROMmemory), working memory 310 (e.g., implemented as RAM memory), and datastore 312 (e.g., implemented as e-prom memory).

FIG. 4 identifies exemplary features of the data server 150. The server150 includes at least one processing logic unit 440 (e.g., CPU)connected to at least one memory device 410, a cache memory 416, atleast one database 414, and at least one communication interface 412.Memory device 410 and databases 414 can be nonvolatile. The interface412 allows the processing logic 440 to send and receive data to/from thedata network 142. The cache memory 416 allows storage of frequently useddata objects so that the processing logic unit 440 may obtain them in anefficient manner. The database 414 contains the actual data objects thatcan be displayed at the user devices via the communicationinfrastructure of system 100.

The data server 150 may also comprise a number of programs 418. Theprograms 418 can include a filter 420 allowing the data objects to beoptimized according to the rendering capabilities of the user devices.The programs 418 may also include an encryption/decryption engine 422allowing data object requests to be decrypted and data objects to beencrypted.

According to a variation, various modules of the data server 150 can beimplemented as separate computers. The separate computers (not shown)may be located together in one facility or located remotely from eachother.

The database 414 can be implemented by any type of storage media. Forinstance, it can comprise a hard-drive, RAM memory, magnetic media(e.g., discs, tape), optical media, etc. The database 414 can be formedusing any type of organization, such as relational, object-oriented,etc. The database 414 can be separated into two or more databases in adistributed fashion. Further, the database (or databases) 414 maycontain redundant data. Any node in system 100 can access the database(or databases) 414, including internal nodes (e.g., access pointsinternal to the data server system) or external nodes (e.g., accesspoints external to the data server system). Thus, the database 414 isintended to very generally represent any type of means of retaining dataobjects.

The term “data objects” likewise is meant to connote a wide variety ofinformation. It may refer to any type of audio information, textualinformation, graphic information, video information, or other types ofinformation, or any combination of such types. The data objects arealternatively referred to as “phonepages” in the following discussion.In one particular embodiment, the data objects pertain to informationwhich may be rendered at appropriate user devices upon the occurrence ofevents within the mobile communication system 125. In alternativeembodiments, the data objects may provide links to some service orfunctionality (e.g., by providing access to an internal or external datanetwork maintained by a subscriber).

FIG. 5 provides an introduction which explains an exemplary use of thedata objects (e.g., the phonepages) within the system 100. Presume thata first user, Bob, has placed a telephone call to a second user, Paul.Further presume, for instance, that Bob (the A-party) uses mobile userdevice 110 to place his call, and Paul (the B-party) uses mobile userdevice 138 to receive Bob's call. Further presume that Paul has defineda series of data objects (e.g., phonepages 502, 504, 506 and 508). Inthis case, Paul is the creator (also referred to as the “holder”) ofthese data objects. Paul's data objects may be personalized to Bob(e.g., by making reference to Bob in the data objects). Alternatively,one or more of Paul's data objects may be generic (e.g., suitable forpresentation to multiple different subscribers). Finally, presume thatBob has access to Paul's data objects (using one of the methods thatwill be described below).

A first trigger event 550 arises when Bob dials Paul's number. Thisprompts the user device 110 to display a data object 502. The dataobject 502 may include a personalized message 510, stating, e.g., “HiBob! Thanks for calling!” The data object may also include pictureinformation, such as a picture 509 of Paul. The data object may alsoinclude textual information 512, such as the name, telephone number, ande-mail address of Paul. The data object may additionally include audioinformation, such as a brief introductory message spoken by Paul. Thiscombination of data object components is entirely exemplary. Other dataobjects may provide a different combination of components, includingadditional types of information. Further, one or more of these dataobject components can be omitted to accommodate user devices that havereduced functionality, such as user devices that lack the capacity todisplay complex graphics.

After setting up the call, the user device 110 may then be configured towait for another call event. In this exemplary case, the next call eventoccurs when Paul puts Bob on hold. This constitutes trigger event 552,which causes the user device to display a second data object 504. Thisdata object 504 provides a message 514 that states, e.g., “I'm going tohave to put you on hold, Bob!” The next event 554 occurs when Paulreturns and takes Bob off hold, which prompts the user device to displaya third data object 506. This data object 504 provides a message 516which states, e.g., “Back with you, Bob!” In this exemplarydemonstration, a final trigger event 556 may occur when either of theparties terminates the call, which prompts the user device to display afourth data object 508. This data object 508 provides a message 518which states, e.g., “Bye Bob, hope to speak with you soon!”

Another set of data objects may be rendered at the called party's userdevice. These data objects pertain to the calling party, and aregenerally created by the calling party (or on his behalf). Thus, in theabove scenario, Paul may be able to view (and/or hear) a plurality ofdata objects in the course of his conversation with Bob.

FIG. 6 illustrates the data components of an exemplary data object 600.The object 600 may include a first data field for storing an eventtrigger (ET) component 601. This component 601 indicates the nature ofthe event that will prompt the presentation of the data object. Forinstance, the ET component 601 may comprise a code that is associatedwith the event, and which serves as an index for use by a user device inretrieving the data object from memory upon the occurrence of theassociated communication event.

Generally speaking, an event trigger may be attributed to one or moreautomatic events (e.g., when a call is terminated by the other party),or may be attributed to a manual event (e.g., when the A-party dials anumber, such as the B-party's number). More specifically, triggeringevents may be associated with the following exemplary list of events: a)an outgoing call is (or is about to be) initiated; b) an addressedB-party answers a call; c) an addressed B-party is busy; d) an addressedB-party does not answer; e) an addressed B-party rejects a call; f) anaddressed B-party is unavailable (e.g., an addressed mobile phone is outof coverage); g) an incoming call is imminent or has just started; h) aconference call is or is about to be initiated; i) a call isdisconnected; j) a call is conducted (under which several triggeringevents can be generated); k) a subscriber is put on hold; l) a new cellin the new Public Land Mobile Network (PLMN) has been selected; m) thelocation of a subscriber has changed; n) a PLMN operator is selected; o)a new country of registration is made; p) a user device is about to beswitched off; q) a user device has been switched on; r) a designatedbutton on a user device is pressed; s) a talk spurt is received by auser device; t) a voice mail has been left to a subscriber; u) an SMShas been sent to a subscriber; and v) a user has commenced review ofmissed calls, received calls, and/or dialed numbers (or is in the courseof review).

The second data field stores a counter component (CO) 602. The countercomponent may be used to indicate the number of times that a data objectshould be sent to a particular user. That is, a user device may lack thecapacity to store a data object. In this case, the CO component maycontain information which indicates that a data object should be sent tothe user device each time a call event occurs. That is, in the abovedemonstration, presume that Bob's device lacked the capacity to storedata objects. In this case, the CO component of the data objects wouldindicate that the transmitting source (e.g., either Paul's user deviceor the data server 150) should transmit the data objects upon everyoccurrence of the triggering events. In contrast, other user devices mayhave the capacity to store the data objects in their local memories(e.g., in the memories of their respective SIM cards). In this case, theCO component may contain information which indicates that the dataobjects should be sent to the users' devices only once.

A third data field may store an audio component (AU) 604. The audiocomponent 604 may contain a recording of the object's creator speakingvarious messages pertaining to the data object. For instance, in thecase of FIG. 5, the first data object may include a voice message fromPaul that states, “Hi Bob!”, or any other type of greeting orinstruction. The audio component may also specify the timing at whichthe audio information is to be rendered. For instance, the audioinformation may be played superimposed over the normal ring signalgenerated by the user device, before the ring signal, or after the ringsignal. The audio component may alternatively indicate that the ringsignal should be disabled. For instance, instead of a normal ring signal(such as the conventional ring or beep) being sounded at a called userdevice, the called user device may be configured to sound a voicemessage created by the calling party (such as, in the above scenariowhere Bob calls Paul, the message might announce, e.g., “Hello, itsBob!”). Further, the system may be configured to suppress theconventional ring signal normally heard by the calling party, andinstead sound a voice message created by the called party (such as, inthe above scenario, when Bob calls Paul, Bob may hear a message in whichPaul announces, e.g., “Be patient, I'm coming,” instead of aconventional ring signal). Other audio messages may be sounded duringthe conversation upon the occurrence of one or more communicationevents. In still other embodiments, the audio component may provide amusical presentation. Still alternatively, the audio component mayprovide a variety of other sounds, such as various recorded orsynthesized sounds (e.g., other than the recorded human voice).

A fourth data field may contain a visual component (VI) 606, generallyencompassing any type of picture, video, graphic, and/or text elementdisplayed at the user's device. For instance, in the case of FIG. 5, thedata objects included a picture of the sender, Paul. The specific natureof these messages is entirely at the discretion of their creators, andmay contain a variety of pictures or other fanciful figures. Generally,it is envisioned that a maker may want to create relatively formal dataobjects for formal acquaintances (e.g., business acquaintances), but maywish to create more personal data objects for friends and family, etc.The visual component may alternatively specify the display of onlytextual messages.

Finally, the fifth data field indicates that the data object may containa variety of other information 608. Such information may include programcode that modifies the functionality of the user's device upon theoccurrence of an event, a link which provides access to remote resources(such as remote data server resources or networks), etc.

FIG. 7 indicates the exemplary contents of the database 414 of dataserver 150 (with reference to FIG. 2). Each subscriber may create aplurality of sets of data objects for display at a respective pluralityof user devices. In this figure, the creator of the data objects isreferred to as a “holder,” while the recipient is referred to as asubscriber. For example, a first holder, “holder 1,” creates a set ofdata objects 710 for subscriber “a.” This set is alternatively denotedby PP_(H-a) (indicating phonepages, PP, created by holder, Hi, forsubscriber “a”). Each of the data objects in this set pertains to adifferent call event (an exemplary list of which was presented above).That is, data object 770 may be triggered by a first event (e.g., by theinitiation of a call), data object 772 may be triggered by a secondevent (e.g., the establishment of a conference call), and data object774 may be triggered by a third event (e.g., by the termination of acall). Holder 1 also creates a second set of data objects 712 forsubscriber “b.” Holder 1 also creates a third set of data objects 714for subscriber “c.” These plural sets of data objects for holder 1constitute its master set of data objects 702. (To the extent that theremay be common data objects used by different subscribers, the dataserver 150 can be configured to store only one copy of these common dataobjects, and to provide suitable indexing to indicate the sets to whichthese common data objects belong.)

Similarly, holder 2 may store plural sets (716, 718, 720) of dataobjects for respective subscribers (d, e, f) to create a master set ofdata objects 704. Similarly, holder 3 may store plural sets (722, 724,726) of data objects for respective subscribers (g, h, i) to create amaster set of data objects 706. Similarly, holder n may store pluralsets (730, 732, 734) of data objects for respective subscribers (j, k,l) to create a master set of data objects 708.

It should be noted that the holder need not define unique sets of dataobjects for each subscriber. In one case, for instance, a holder maydefine a single set (e.g., series) of data objects for a class ofsubscribers. Further, there may be administrative advantages toencouraging the holders to design data objects from a common basetemplate (or series of templates). Additional details regarding the useof base templates are provided in section No. 3 of this disclosure.

2. System Operation

Having described the exemplary architecture and functional features ofthe system 100, its operation will now be discussed.

A primary objective of the system is to supply data objects to the userdevices for rendering thereat. Several techniques are envisioned forperforming this task. By way of overview, in a first technique, a masterset of data objects is created on the data server 150. The master set isthen transferred to the holder's user device. Upon the occurrence of acall event pertaining to one of the subscribers identified in the masterset, the appropriate set of data objects is transferred from theholder's user device to the subscriber's user device. The set of dataobjects is then rendered by that subscriber in the course of the call(or other event). In a second technique, a master set of data objects iscreated on the data server 150. The master set is then directlydisseminated to appropriate user devices identified in the master set.Each user device then renders its set of data objects upon theoccurrence of communication events. In a third technique, the userdevice may request that the data server download one or more dataobjects at any time, e.g., when an event arises for which the holder hascreated one or more data objects.

FIG. 8 shows a sequence of steps appropriate for the first identifiedtechnique. In step 802, data objects are created. The holder (or otherentity) may perform this function by accessing the data server 150 via acomputer device (e.g., computer device 146 or device 148) and thendesigning the data objects. For instance, the user may design one ormore data objects via a “web” interface. This data path is denoted aspath 152 in FIG. 1. Alternatively the holder (or other entity) maydirect the creation of the data objects via a mobile station device(e.g., such as mobile telephone 110).

In an alternative embodiment, an operator of the data server 150 (orsome other entity) may create or assign one or more default data objectson behalf of a user. The creation or assignment of data objects may betriggered by the user subscribing to a data object-related service (orsome other service), or by some other manual or automatic event. Thisfeature potentially generates a great number of data objects in a shortperiod of time without burdening individual users to create their owndata objects. At the same time, the system may be configured to allowany user to modify the default data objects created or assigned for themto create unique data objects.

In step 804, the data server 150 downloads a master set of data objectsto the holder's user device (e.g., user device 110). This data path isdenoted as path 154 in FIG. 1. The system 100 may perform this transferusing anyone of a variety of different types of messaging platforms andprotocols. For instance, the data objects can be transmitted using theShort Message Service (SMS) protocol (commonly used in GSM systems, forinstance). In this protocol, the information is transmitted through thedata network 142 and gateway 140 to message center 126, and isthereafter transferred to the holder's user device (e.g., user device110). The information may also pass through the PSTN network 128depending on the location of the addressed holder's user device and/orthe architecture of the system (e.g., generally the SMS information maybe transported from one PLMN to another using an SS7 signaling network,that may or may not form part of the PSTN). In step 806, the holderreceives the data objects from the data server 150 and stores the dataobjects.

In step 808, the holder's user device awaits for the occurrence of anevent which pertains to one of the subscribers represented in the masterset of data objects (i.e., referred to here as an “identifiedsubscriber”). This may comprise, for example, a telephone call placed tothe holder by an identified subscriber. In response thereto, theholder's user device transfers the appropriate set of data objects tothe identified subscriber (in step 810). This transfer may beimplemented using anyone of a variety of message protocols. Forinstance, the data objects can be transmitted using the Short MessageSystem (SMS) protocol. In step 812, the holder's user device thenhandles the call event, e.g., by conducting a voice communicationsession with the identified subscriber. In alternate embodiments, theholder may manually initiate the transfer of the data objects (e.g., bymaking an appropriate selection on the keyboard of the holder's userdevice). In alternative embodiments, the holder's user device mayautomatically transfer the data objects (e.g., immediately upon receiptfrom the data server 150, or at another time).

FIG. 9 shows the flow of data objects through the system pursuant to theprocedure of FIG. 8. As indicated there, the data objects are created atthe data server 910 using computer device 908 (or other type ofinterfacing device). This data path is labeled as path 930. The dataobjects are thereafter transferred through the data network 906 to theholder's user device 904 via path 932. This path is shown to involve atransfer over the PSTN 902 (but this need not be so, e.g., depending onwhere the data network feeds into the MSC and other factors).Thereafter, the data objects are distributed over the PSTN 902 toidentified subscribers. Namely, for master set 702 shown in FIG. 7, dataobject set PP_(H1-a) is transferred to subscriber “a” 912, data objectset PP_(H1-b) is transferred to subscriber “b” 914, and data object setPP_(H1-c) is transferred to subscriber “c” 916.

FIG. 10 illustrates the second technique for supplying data objects to auser device. In step 1002, the holder (or other entity) creates a masterset of data objects at the data sever 150, e.g., using a computer device146 or other type of interfacing device. In step 1004, the holder storesthe master set of data objects at the data server 150.

In step 1006, the data server receives the master set of data objects.In step 1008 the data server then determines whether it should transferthe data object sets in the master set of data objects to theappropriate recipients. Different systems may be configured to usedifferent factors to determine when to download data object sets. In oneembodiment, the data objects are transferred immediately after creationby the holder (or other entity). In another embodiment, the data objectsare transferred upon the request of the holder (or other entity). In athird embodiment, the data object sets are transferred to appropriateuser devices during times when the system is not heavily burdened with alarge communication load (e.g., during early morning hours). In step1010, the data server 1010 forwards the data objects directly to theidentified subscribers. A variety of message formats can be used toperform the transfer, such as the Short Message Service (SMS) protocol.

FIG. 11 shows the flow of data objects through the system pursuant tothe procedure of FIG. 10. As indicated there, the data objects arecreated at the data server 1133 using computer device 1132 (or othertype of interfacing device). This data path is illustrated as path 1135.The data objects are thereafter directly transferred through the datanetwork 1106 to identified subscribers. The data objects are alsopotentially transferred through PSTN 1102 depending on the location ofthe addressed subscribers and/or the architecture of the system (e.g.,generally the SMS information may be transported from one PLMN toanother using an SS7 signaling network, that may or may not form part ofthe PSTN). As a result, for the master set 702 shown in FIG. 7, dataobject set PP_(H1-a) is transferred to subscriber “a” 1112, data objectset PP_(H1-b) is transferred to subscriber “b” 1114, and data object setPP_(H1-c) is transferred to subscriber “c” 1116.

One possible complication of the above-described technique pertains tothe charging arrangement employed by the SMS messaging service. Some SMScharging arrangements specify that the sender of the message pays forthe message transfer. This would imply that the data server operatorwould be saddled with the cost of the transfer. However, this cost maybe circumvented in various ways. For instance, the message center 126 ofthe mobile communication system 125 may be configured to require thatthe holder transmit an SMS message to the message center 126 to triggerits delivery of data objects to the designated subscribers. This triggersignal can designate the billing event. Alternatively, the data servermay simply pass down the costs of message transfer to the holders. Theholder can also send an SMS message to the data server 150 to triggerits transfer of the data objects to the designated subscribers.

FIG. 12 shows a sequence of steps used by a user device to render (e.g.,display) the data objects stored in its local memory. In step 1202, theuser device receives the data objects (which have been transferred bythe method of FIG. 8 or FIG. 10, or by some other method). In step 1204,the user device stores the data objects. In step 1206, the user devicedetermines whether a triggering event has occurred. Exemplary triggeringevents were discussed above. If a triggering event has occurred, theuser device retrieves the appropriate data object (in step 1208). Morespecifically, in one exemplary embodiment, an appropriate set of dataobjects (e.g., pertaining to a holder) may be identified by identifyingthe party with whom the user is communicating (e.g., by noting thetelephone number of that party which is transmitted to the user devicein the course of setting up a call). A particular data object withinthat set may be accessed by matching a code associated with the eventthat has occurred with a corresponding code associated with the dataobject. In step 1210, the user device renders the data object. In step1212, the user device handles the call event (e.g., by placing orreceiving a call, etc.).

FIG. 13 provides another technique that the user device can use toobtain one or more data objects from the data server. The techniquebegins at step 1302, in which the user device determines whether atriggering event has occurred (which may include anyone of theabove-identified user events). In step 1304, the user device sends adata object request to the data server. In step 1306, the user devicereceives the requested data object from the data server. In step 1308,the user device renders the received data objects.

The data object request in step 1304 may specifically include at leastone of the following parameters: a) a requested protocol to be used fortransmission (e.g., WAP, WML, HDML, HTML, XML, etc.); b) anidentification of a data object server (e.g., a server name or a plainIP address); c) a code denoting what kind of event triggered the dataobject request (e.g., outgoing call setup); d) the indicated B-numberassociated with at least one B-party equipment; e) an A-party identityand/or a secret A-party identity (e.g., an A-number of a mobilestation); f) a network address of the A-party (e.g., IP address) used bythe data object server when returning a requested data object; g) acapability code indicating the displaying capabilities of the A-party(e.g., screen resolution, audio, etc.); h) a code indicating anencryption scheme or encryption key used; i) a code indicating thecountry that the mobile station is registered in (i.e., country code);j) a code identifying the current PLMN (V-PLMN) operator or the PLMNwhere the A-party has a subscription (H-PLMN) or both; k) a codeindicating the vendor of the mobile station and the type of the mobilestation.; l) a code indicating a unique equipment identity; and m) avalidation code (e.g., a checksum) of the parameters.

In an alternative embodiment, a subscriber may “manually” retrieve oneor more data objects from the data server (e.g., by making appropriateselections on the keyboard of the user device). This selectionconstitutes the triggering communication event.

FIG. 14 shows corresponding procedures performed in a data object server(such as data object server 150) in response to the procedures shown inFIG. 13. Namely, in step 1402, the data server receives a request for adata object (or objects). The request typically includes (in exemplaryembodiments) at least an indication specifying an A- or B-number and aspecification of what kind of action triggered the request. The addressindication (e.g., A- or B-number) is mapped to a memory address in thedata object server, or to an address provided in another databasemaintained at some other site. The address may specify a data object,such as a phonepage. The data server retrieves the data object in step1404. The request received in step 1402 may also include an indicationof a user device display capability. In this case, the data server mayadapt the retrieved data object to the requested format in step 1406.Alternatively, the database may store the data objects in differentformats. In this case, the data server complies with the request byretrieving the data object having the correct format. The data serversends the data object in step 1408.

Various data transfer mechanisms can be used to transfer the data (e.g.,requests and data objects) discussed in FIGS. 13 and 14. For instance,SMS messaging can be used. Alternatively, a GPRS data path can be used.Further details regarding the transfer of information using a GPRSchannel may be found in the applications identified in the CROSSREFERENCE TO RELATED APPLICATIONS section of this disclosure.

3. Variations

The above-discussed system and method can be modified in various ways.For instance, all information transmitted over the data network 142and/or PSTN 128 20 (or some other network) may be encrypted prior totransfer to ensure message privacy. The receiving site could thendecrypt the transmitted information prior to display or processing. Forinstance, the data server may encrypt data objects prior to transfer tothe holder's or subscribers' user devices. The user devices can thendecrypt the data objects prior to rendering them. The user devices mayalso encrypt any requests, messages, data objects, etc., that thedevices send to other entities, such as other user devices or the dataserver.

In another variation, the memories of the user devices may be configuredin the manner shown in FIG. 15. In that figure, an exemplary memory 1502includes standard (i.e., non-variable) data 1504. The standard data 1504may specify one or more base templates. The base templates may pertainto common elements in the data objects designed by plural holders (e.g.,where multiple holders are using the same basic phonepage layout todesign their pages). In addition, or alternatively, the base templatesmay pertain to common features within a particular holder's set of dataobjects (e.g., where the holder has several phonepages that share thesame background scene). On the other hand, the memory 1502 also includesdelta (i.e., variable) data 1506. The delta data pertains to the uniquefeatures of the rendered data objects. The unique features refer to thefeatures of the rendered data objects which distinguish them from thebase templates stored in the standard data 1504.

FIG. 16 shows one example of a standard data portion 1602 and delta-dataportion 1604 for an exemplary data object. This figure also shows howthese two portions are combined to produce the rendered object 1608.More specifically, for this data object, the standard data portion 1602may provide a base template with a generic message. The message hasfields 1650 that can be filled in with text to personalize the message.Further, the standard data portion 1602 includes a field 1652 that canbe filled in with an audio message to further personalize the dataobject. The delta-data portion 1604, on the other hand, comprises thepersonalized text “Bob” coupled with the personalized audio greeting,such as “please call back.” The delta data is “added” to the standarddata portion to produce the rendered data object 1608.

The storage format shown in FIG. 15 provides for more efficient storageand transfer of data objects. With reference to FIG. 17, for instance, auser device 1706 (operated by subscriber “a”) may store standard data“s” in its memory. This standard data may be used to render a pluralityof data objects. Storage of a single copy of such redundant data reducesthe storage requirements of the user device. Further, when the userdevice 1706 receives additional data objects which use the standard datain their design, it is only necessary to transfer the delta-data to theuser device 1706 (such as delta-data 1708 for data object PP_(H1-a))

In one embodiment, the standard data can be transferred to the userdevices at any time (e.g., not necessarily when a communication eventoccurs). In one embodiment, the SIM card provided to the user mayalready contain standard data containing one or more common data objecttemplates.

According to another variation, the Unstructured Supplementary ServicesData (USSD) protocol may be used to transmit data objects to the userdevices, instead of, or as a supplement to, the use of the SMS protocol.USSD and SMS are alike in that they both may use the GSM system'ssignaling path to transmit data messages. But, the USSD protocol doesnot define a store-and-forward type of service, unlike the SMS protocol.Still other protocols can be used to transfer data objects.

FIG. 18 shows another variation. More specifically, this figure showsstructure which varies from previous figures by including a computerdevice 1810 coupled to an interface unit 1812, which, in turn, iscoupled to user device 814. In one embodiment, the computer device 1810may comprise a personal computer device. The interface unit 1812 maycomprise any coupling mechanism for transferring information between thecomputer device 1810 and the user device 1814. The link between thecomputer device 1810 and the user device 1814 may comprise a hardwiredlink, a wireless link (e.g., radio or infrared), or some other type oflink. In one embodiment, the interface unit 1812 may further comprise asocket-type of coupling mechanism (not shown) which receives the userdevice 1814 and which includes appropriate terminals (not shown) formating with input/output terminals (not shown) provided on the userdevice 1814.

The operation of the system shown in FIG. 18 has similarities to theprocedure shown in FIG. 10. Namely, the holder (or other entity) createsa master set of data objects at the data sever 1806, e.g., using acomputer device 1804 or other type of interfacing device. The dataserver 1806 then receives and stores this master set of data objects.

The data server 1806 then determines whether it should transfer the dataobject sets in the master set of data objects to the appropriaterecipients. Different systems may be configured to use different factorsto determine when to download data object sets. In one embodiment, thedata objects are transferred immediately after creation by the holder(or other entity).

In another embodiment, the user device 1814 sends a request to dataserver 1806 via the computer device 1810. The request may instruct thedata server 1806 to download one or more data objects to computer device1810. More specifically, the user device 1814 may instruct the dataserver 1806 to send updated data objects pertaining to the data objectsthat are stored in the user device's local memory (e.g., in the userdevice's phonebook stored in the SIM card, or in another memory of theuser device). Alternatively, the user device 1814 may simply instructthe data server 1806 to send whatever data objects the data server 1806independently determines should be downloaded to the user device 1814.Still alternatively, the user device 1814 may instruct the data server1806 to send updated data objects pertaining to the data objects storedin the user device's local memory, but the data server 1806 stillexercises independent judgment whether it complies with this request inwhole or in part.

In another embodiment, the computer device 1810 independently sends arequest to the data server 1806. That is, the computer device 1810 maysend a request to the data server 1806 even when the user device 1814 isnot coupled to the computer device 1810 via the interface unit 1812. Therequest may instruct the data server 1806 to download one or more dataobjects to the computer device 1810. More specifically, the computerdevice 1810 may instruct the data server 1806 to send updated dataobjects pertaining to the data objects that are stored in the userdevice's local memory (e.g., in its user device's phonebook stored inthe SIM card, or in another memory of the user device). In analternative embodiment, the computer device 1810 may be configured tosend a request to the data server 1806 on a periodic basis.

In another embodiment, the data server 1806 initiates transfer of dataobjects to the computer 1810 without being specifically requested to doso by the computer 1810 or the user device 1814. That is, the dataserver 1806 may use its own “time table” to determine when to downloaddata objects. In an alternative embodiment, the computer device 1810,user device 1814, or some other entity (e.g., the holder) may send aninstruction to the data server 1806 which specifies the frequency atwhich the data server 1806 should download data objects to the computer1810. For instance, the subscriber operating user device 1814 mayinstruct the data server 1806 to download data objects for a particularholder on a relatively frequent basis if that particular holder is knownto change his data objects frequently.

Those skilled in the art will recognize that still further variationscan be used to determine the timing at which data objects aretransferred to subscriber “a”, as well as to determine the identity ofthose data objects that are transferred.

If it is time to transfer the data objects, the data server 1806transfers the objects directly to the recipients' computer devices. Inthe FIG. 18 scenario, the data server 1806 transfers a set of dataobjects PP_(H1-a) to subscriber a's computer device 1810. Transfer maybe via conventional protocol over the data-packet network 1808. Uponreceiving the data objects, the computer device 1810 then transfers thedata objects via the interface 1812 to the subscriber's user device1814.

Other modifications to the embodiments described above can be madewithout departing from the spirit and scope of the invention, asencompassed by the following claims and their legal equivalents.

1. A method for managing data objects in a communication network, themethod comprising: storing a plurality of data objects corresponding toa first communication device and a second communication device, each ofthe data objects having an associated communications-related eventtrigger that will prompt rendering of that data object at the secondcommunication device; and transferring the plurality of data objects tothe second communication device, for rendering by the secondcommunication device upon detection of one or more of the associatedcommunications-related event triggers.
 2. The method of claim 1, whereinsaid storing and transferring are performed at a data object server, themethod further comprising first receiving the plurality of data objectsat the data object server.
 3. The method of claim 1, wherein saidstoring and transferring are performed at the first communicationdevice, the method further comprising first receiving the plurality ofdata objects from a data object server.
 4. The method of claim 1,wherein at least one of the data objects comprises a link for use by thesecond communication device in accessing a remotely located service. 5.The method of claim 1, wherein at least one of the data objectscomprises program code for execution by the second communication devicein response to the associated communications-related event trigger. 6.The method of claim 1, wherein at least one of the data objectscomprises audio data for rendering by the second communication as a ringsignal.
 7. The method of claim 1, wherein at least one of the dataobjects comprises a counter data field specifying how many times thedata object should be transmitted to the second communication device. 8.A data object server in a communications network comprising: storagehardware configured to store a plurality of data objects correspondingto a first communication device and a second communication device, eachof the data objects having an associated communications-related eventtrigger that will prompt rendering of that data object at the secondcommunication device; and processing logic configured to transfer theplurality of data objects to the second communication device, forrendering by the second communication device upon detection of one ormore of the associated communications-related event triggers.
 9. Thedata object server of claim 8, wherein at least one of the data objectscomprises a link for use by the second communication device in accessinga remotely located service.
 10. The data object server of claim 8,wherein at least one of the data objects comprises program code forexecution by the second communication device in response to theassociated communications-related event trigger.
 11. The data objectserver of claim 8, wherein at least one of the data objects comprisesaudio data for rendering by the second communication as a ring signal.12. The data object server of claim 8, wherein at least one of the dataobjects comprises a counter data field specifying how many times thedata object should be transmitted to the second communication device.13. A first communication device comprising: a memory configured tostore a plurality of data objects corresponding to a secondcommunication device, each of the data objects having an associatedcommunications-related event trigger that will prompt rendering of thatdata object at the second communication device; and control logicconfigured to transfer the plurality of data objects to the secondcommunication device, for rendering by the second communication deviceupon detection of one or more of the associated communications-relatedevent triggers.
 14. The first communication device of claim 13, whereinat least one of the data objects comprises a link for use by the secondcommunication device in accessing a remotely located service.
 15. Thefirst communication device of claim 13, wherein at least one of the dataobjects comprises program code for execution by the second communicationdevice in response to the associated communications-related eventtrigger.
 16. The first communication device of claim 13, wherein atleast one of the data objects comprises audio data for rendering by thesecond communication as a ring signal.
 17. The first communicationdevice of claim 13, wherein at least one of the data objects comprises acounter data field specifying how many times the data object should betransmitted to the second communication device.